\chapter{Uma arquitetura baseada em Espaço de Tuplas para redes IMS}
\label{cap:arquitetura}
% ----------------------------------------------------------------------------

%%----------------------------------------------------------------------------
% Visão Geral da Arquitetura
%
\section{Definição da Arquitetura}

  A definição da arquitetura pode ser separada em duas etapas: (i) a reestruturação das
camadas do protocolo SIP, tradicionalmente baseado no modelo requisição/resposta, para um
modelo baseado em espaço de tuplas (padrão \textit{publish/subscribe}); (ii) a
definição de uma infraestrutura distribuída também com base no paradigma de espaço de
tuplas, construído sobre uma rede P2P, para implementação dos elementos responsáveis pelo
controle de sessão da arquitetura IMS (P-CSCF, I-CSCF, S-CSCF e HSS).  
A Figura \ref{fig:arquitetura-cscf} apresenta uma visão geral da arquitetura, e seus
elementos lógicos (componentes de software) e físicos (infraestrutura), \cite{icin2012}.

   \begin{figure}[ht]
     \centering
     \includegraphics[scale=0.75]{figuras/fig-arquitetura.png}
     \caption{Visão geral da arquitetura baseada em espaço de tuplas.}
     \label{fig:arquitetura-cscf}
   \end{figure} 

  Sob o aspecto físico, é possível observar a existência de servidores conectados a uma
rede P2P, responsáveis por hospedar a plataforma baseada em espaço de tuplas
(\textit{Tuple Space-base Platform}), e dispositivos cliente (e.g celulares, tablets,
computadores pessoais, entre outros) conectados aos servidores.

  Sob o aspecto lógico, é possível observar uma arquitetura em camadas (representada no
elemento \textit{node1}), conforme descrito a seguir:

%% OBS: olhar o relatorio tecnico sobre espaço de tuplas da UFRGS

  \begin{itemize}
   \item \textit{Camada da Rede P2P}. A arquitetura define como base uma camada de
rede P2P estruturada seguindo o modelo baseado em DHT. Esta camada é responsável por
construir a rede P2P e coordenar a comunicação entre os Servidores IMS da rede.

    \item \textit{Camada do Espaço de Tuplas}. A camada de espaço de tuplas considera a
construção de um espaço de tuplas local (LTS) executado em cada um dos servidores, e um
espaço de tuplas distribuído (DTS) construído sobre a rede P2P. Ambos seguindo a semântica
da linguagem Linda. 

    \item \textit{Camada SIP}. A camada SIP representa a implementação do protocolo SIP
utilizando a abordagem baseada em espaço de tuplas. Apesar da mudança de paradigma, a
arquitetura prevê a manutenção da semântica do protocolo, conforme será detalhado mais à
frente.

    \item \textit{Camada IMS}. A camada IMS é responsável pela implementação do componente
CSCF e seus elementos. A principal característica da arquitetura é que cada servidor
IMS pode atuar como P-CSCF, S-CSCF, ou I-CSCF, dependendo do tipo de tupla que recebe.

  \end{itemize}

   Adicionalmente, a arquitetura estabelece que todo Servidor IMS terá uma base de
dados HSS local, ou seja, distribuir as consultas ao HSS é uma característica natural da
arquitetura. 

   Completando a arquitetura, foi definido o componente \textit{Services} que pode
ser utilizado em qualquer umas das camadas. Esse componente possibilita a implementação de
serviços adicionais tais como negociação de QoS, tarifação em tempo real, entre outros.

  As principais diferenças em relação à arquitetura IMS padrão são: 
  \begin{enumerate}
   \item A comunicação entre os elementos passa a ser feita através do espaço de
tuplas, ou seja, toda operação SIP entre os elementos (dispositivos cliente e
servidores) terá ao menos duas tuplas, uma de requisição e uma de resposta.

   \item Cada servidor na rede pode atuar como P-CSCF, S-CSCF ou I-CSCF,
dependendo do tipo de requisição que receber. Com isso, teremos um melhor
aproveitamento dos recursos computacionais.

   \item Distribuição do HSS, uma vez que cada servidor na rede possui um
HSS local.
  \end{enumerate}


%
% SIPSpace
%
\subsection{SIPSpace: SIP baseado em espaço de tuplas}

     O SIPSpace é o componente responsável pela implementação do protocolo
através da abordagem baseada em espaço de tuplas. A Figura \ref{fig:sipspace}
ilustra sua arquitetura.

   \begin{figure}[ht]
     \centering
     \includegraphics[scale=0.7]{figuras/fig-sipspace-arch.png}
     \caption{Visão geral da Arquitetura do SIPSpace}
     \label{fig:sipspace}
   \end{figure}

  De acordo com a especificação, \cite{rfc3261}, a arquitetura do protocolo SIP é
separada em três camadas: \textit{core}, responsável pela definição da sintaxe e formatos
de mensagens; \textit{transaction}, responsável pelas máquinas de estado do protocolo
(e.g \textit{Client Transaction} e  \textit{Server Transaction}); e \textit{transport},
responsável pelo envio e recebimento de mensagens. Na arquitetura do SIPSpace, a camada
\textit{transport} é alterada para fazer o acesso ao espaço de tuplas, mantendo a
semântica do protocolo. 

  Podemos considerar dois pontos importantes na arquitetura do SIPSpace, com relação ao
suporte aos requisitos de larga escala:

\begin{enumerate}
 
  \item \textit{Registro e Serviço de localização}. A arquitetura baseada em espaço de
tupla possibilita total distribuição do servidor de registro do protocolo SIP. Em
primeira instância, as informações de registro são tuplas armazenadas no DTS (em memória
ou persistente). Para a localização de um determinado dispositivo registrado, basta ao
serviço de localização executar uma operação de leitura no espaço de tupla. Como a
arquitetura considera a implementação do DTS sobre uma rede P2P baseada em DHT, uma busca
pode ser feita em $O(logN)$ passos, onde $N$ representa o número de servidores na rede,
conforme demonstrado por \cite{chord}.

 \item \textit{Manutenção de sessão}. Da mesma forma que o registro de dispositivos,
uma sessão será tratada como uma tupla. Dessa forma, qualquer servidor disponível na rede
poderá ter acesso às informações da sessão, podendo alterá-la a qualquer momento a partir
da ocorrência de algum evento (e.g acesso a novo serviço, transmissão de uma
imagem, etc.).
 
\end{enumerate}


%
% Espaço de Tuplas sobre P2P
%
\subsection{Espaço de tuplas sobre redes P2P}

  Para o espaço de tuplas, a arquitetura apresentada neste trabalho indica um modelo
baseado em redes P2P estruturadas, utilizando DHT como estratégia para organização dos
Servidores IMS. A Figura \ref{fig:proposta-topologia} ilustra a topologia do espaço de
tuplas
sobre redes P2P.

  \begin{figure}[ht]
    \centering
    \includegraphics[scale=0.7]{figuras/fig-proposta-topologia.png}
    \caption{Topologia da arquitetura baseada em espaço de tuplas}
    \label{fig:proposta-topologia}
  \end{figure} 

   Como pode-se observar, existe três tipos de elementos: (i) Servidores IMS (\textit{IMS
Servers}), que hospedam os elementos da arquitetura; (ii) Servidores de Aplicação
(\textit{Application Servers}), que hospedam serviços específicos disponíveis aos
usuários; e (iii), os agentes (\textit{SIP User Agents}), que são os dispositivos móveis
propriamente ditos. 

   A arquitetura utiliza o conceito de \textit{super-peers}, representados pelos
servidores IMS, ou seja, a rede P2P é formada apenas pelos servidores IMS
(\textit{super-peers}). Os outros elementos, servidores de aplicação e dispositivos se
comunicam diretamente com um determinado \textit{super-peer}. 


   As tuplas foram classificadas em três tipos: tupla de sessão, tupla de
operação SIP e tupla de registro, cada uma com características e comportamentos
específicos em relação à execução local (LTS) ou distribuída (DTS).


\begin{itemize}

 \item \textit{Tuplas de Operação}. Tuplas de operação representam as operações
relacionadas ao estabelecimento de sessão do protocolo SIP, e.g INVITE, CANCEL, BYE,
PRACK e ACK. Esse tipo de tupla é enviada pelo dispositivo cliente e publicada no
LTS. Em caso de sobrecarga do servidor IMS de origem, o componente Event Processor irá
publicá-la no DTS, para que qualquer outro servidor IMS com carga menor possa realizar o
processamento.

 \item \textit{Tuplas de Registro}. Tuplas de registro correspondem especificamente à
operação REGISTER do protocolo SIP. Assim como as tuplas de operação, as tuplas de
registro serão publicadas no LTS pelos dispositivos cliente. Ao ser concluído o processo
de registro de dispositivo na rede, a tupla de registro é publicada no DTS para
possibilitar eficiência na localização de dispositivos. 

 \item \textit{Tuplas de Sessão}. As Tuplas de sessão são criadas no DTS após a
confirmação do estabelecimento de uma sessão por parte dos dispositivos cliente
envolvidos, ou seja, uma tupla de sessão representa a própria sessão multimídia em curso.
A tupla de sessão deve ficar no DTS para possibilitar eficiência na localização e
manutenção, pois poderá ser alterada com frequência.

\end{itemize}


  Considerando que o espaço de tuplas distribuído é formado pelo compartilhamento de
memória de todos os servidores IMS conectados à rede P2P, é necessário um mecanismo de
replicação que garanta a disponibilidade da tupla enquanto estiver ativa e que seja
facilmente acessada a partir de qualquer um dos Servidores IMS.

  Nesse sentido, foi definido o algoritmo a seguir para replicar tuplas no DTS visando
manter o mínimo de réplicas necessárias. 

    \begin{algorithm}
      \caption{$ReplicarTupla(S)$}
      \begin{algorithmic}[1]
        \medskip
        
        \WHILE{$rc < n$}
        \IF{$PF > p$ \textbf{and} $T.TTL > t$}
          \STATE replica tupla $S$ no DTS seguindo o modelo da rede P2P em função do
algoritmo DHT utilizado.
            \COMMENT{Importante observar que a réplica da tupla nasce com o $T.TTL$ da
tupla principal, ou seja, o $T.TTL$ é o mesmo para toda réplica.}
          \STATE incrementa $rc$
          \STATE incrementa $t$
        \ENDIF
        \ENDWHILE
        \medskip
        
        \COMMENT{onde: $PF$ é a probabilidade de falha do servidor, $p$ é um parâmetro do
sistema que indica a probabilidade máxima aceita, $T.TTL$ é o tempo de vida da
tupla, $t$ é o tempo máximo para que uma tupla seja replicada, $rc$ é o número
de réplicas da tupla e $n$ é o número máximo de réplicas permitidas no sistema.}
      \end{algorithmic}
    \end{algorithm}

   A replicação de tuplas irá ocorrer em função da probabilidade de falha do servidor e
do tempo de vida da tupla, ou seja, decorridos um tempo de vida $T.TTL$, a tupla
será replicada em um determinado servidor. A cada intervalo de tempo de vida
$T.TTL$, a tupla será replicada novamente, até atingir um número máximo de
réplicas.

   Cada Servidor IMS tem sua probabilidade de falha, que pode, por exemplo, ser definida
em função da carga\footnote{O estudo de probabilidades de falha de servidores, bem como a
definição de uma função de probabilidade de falha para o algoritmo de replicação, ficou
fora do escopo deste trabalho.}. O tempo $t$ varia para cada réplica, ou seja, o
$t$ aumenta após cada replicação, fazendo com que o intervalo de replicação de uma
única tupla aumente ao longo do tempo, evitando replicações excessivas.


%
% Operacao da rede
%
\subsection{Aspectos Operacionais}

  Considerando que a arquitetura é baseada em espaço de tuplas, o mecanismo básico de
operação da rede é a publicação e leitura de tuplas (operações \texttt{out(..)} e
\texttt{in(..)}). O componente \textit{Events Processor}, parte do SIPSpace conforme
mostra a Figura \ref{fig:sipspace}, é o responsável pela leitura de tuplas tanto do LTS
quanto do DTS. A leitura é feita em paralelo, desacoplada dos elementos funcionais da
arquitetura IMS. A Figura \ref{fig:operacao} ilustra de forma simplificada o modo de
operação do servidor IMS.
 
  \begin{figure}[ht]
    \centering
    \includegraphics[scale=0.65]{figuras/fig-operacao.png}
    \caption{Modo de operação do servidor IMS (simplificado)}
    \label{fig:operacao}
  \end{figure}

  \begin{enumerate}
   \item Para iniciar uma sessão ou se registrar na rede, o dispositivo publica uma tupla
no LTS do servidor IMS ao qual estiver conectado. 

   \item O \textit{Event Processor} lê a tupla do LTS.
   
   \item O \textit{Event Processor} faz uma chamada assíncrona ao CSCF para realizar o
processamento da requisição. 

   \item Caso o CSCF esteja sobrecarregado, o \textit{Event Processor} irá publicar a
tupla no DTS para que seja lida e processada por qualquer outro servidor IMS da
rede, ao invés de fazer a chamada assíncrona ao CSCF. 

   \item Se o \textit{Event Processor} publicou a requisição no DTS, a resposta
também será publicada no DTS pelo servidor IMS que realizou o processamento. Neste caso,
o \textit{Event Processor} faz a leitura da resposta publicada no DTS.

   \item Se o \textit{Event Processor} recebeu a resposta pelo DTS, este também fará uma
chamada assíncrona para o CSCF finalizar o processamento.
   
   \item Ao final do processamento, o CSCF local publica uma tupla de resposta no LTS.
   
   \item Por fim, o dispositivo faz a leitura da tupla de resposta do LTS. A sequência de
mensagens continua da mesma forma de acordo com o protocolo SIP.

  \end{enumerate}

  Cada servidor IMS possui as mesmas características em termos de componentes de software
e conectividade na rede. Essa característica permite que qualquer Servidor IMS da rede
seja capaz de processar qualquer tipo de requisição.

  A característica do servidor IMS aliada ao modelo de rede P2P adotado, possibilita a
inclusão de novos servidores IMS na rede sem grandes esforços. 

  Um novo Servidor IMS na rede, ao ser iniciado, irá se conectar à rede P2P e o DHT se
encarrega de reorganizar a estrutura. Após ser adicionado à rede, o Servidor IMS está apto
a processar tuplas que estejam publicadas no DTS e receber requisições de dispositivos
cliente.




%
% Aspectos de Implementacao
%
\subsection{Aspectos de Implementação}\label{impl}

   Para ilustrar uma abordagem de implementação da arquitetura, tomamos como base a
especificação JAIN-SIP, \cite{jainsip}, definida pelo \textit{Java\texttrademark
Community Process} através da JSR-32, e o \textit{framework} LighTS, \cite{lights}, para
construção de espaços de tupla. 

   O JAIN-SIP é uma especificação aberta que serve como base para implementação do
protocolo SIP utilizando tecnologia Java\texttrademark. A Figura
\ref{fig:jainsip-arquitetura} mostra a arquitetura da API JAIN-SIP.
  
  \begin{figure}[ht]
    \centering
    \includegraphics[scale=0.3]{figuras/fig-jainsip-arquitetura.png}
    \caption{Arquitetura JAIN-SIP}
    \label{fig:jainsip-arquitetura}
  \end{figure}

   Implementações de JAIN-SIP são denominadas \textit{providers}. Considerando a
arquitetura apresentada neste trabalho, podemos dizer que o SIPSpace é um
\textit{provider} para o JAIN-SIP que utiliza um modelo de comunicação baseado em espaço
de tuplas. 
   
   Os fragmentos de código a seguir ilustram o SIPSpace implementando as interfaces
\textit{stack} e \textit{provider} do JAIN-SIP. 


\begin{verbatim}

 package br.usp.pcs.larc.sipspace.jainsip.javax.sip;
 public class SipStackImpl implements javax.sip.SipStack{
        private Properties stackConfig = null;
        public SipStackImpl(Properties p) {
                this.stackConfig = p;
        }
        ...
        public SipProvider createSipProvider(ListeningPoint lp)
                        throws ObjectInUseException {
                return new SipProviderImpl();
        }
 }
 
 package br.usp.pcs.larc.sipspace.jainsip.javax.sip;
 public class SipProviderImpl implements javax.sip.SipProvider{
   
 }
\end{verbatim} 

  Conforme mencionado anteriormente, o LighTS é um \textit{framework} para implementação
de espaço de tuplas que segue a semântica da linguagem Linda. Assim como o JAIN-SIP
oferece interfaces para implementação do protocolo SIP, o LighTS oferece interfaces para
implementação de espaço de tuplas. A interface \texttt{ITupleSpace} contém as operações
básicas definidas pela linguagem Linda, tais como, publicação de tuplas (\texttt{out}) e
as operações bloqueantes de consulta (\texttt{rd} e \texttt{in}). As interfaces
\texttt{IField} e \texttt{ITuple} são utilizadas para descrever uma tupla. 

  Adicionalmente, para reduzir o tráfego na rede é possível utilizar o formato JSON para
publicação e leitura de tuplas. JSON é um formato leve para troca de mensagens. Em testes
simples, a mesma informação representada como objeto Java\texttrademark quando serializada
utilizando \texttt{java.io.ObjectOutputStream} tem um tamanho duas vezes maior que
serializando no formato JSON. O mesmo acontece quando comparada a serialização JSON com o
formato XML, sendo o XML duas vezes maior que o formato JSON.

  O LighTS pode ser estendido para comportar a utilização de JSON para representar o
conteúdo de um tupla. Isso é possível pela criação de interfaces que estendem as
interfaces padrão do LighTS, tais como \texttt{FieldMessage} e \texttt{ITupleJSON},
conforme fragmentos de código apresentados a seguir.

\begin{verbatim}
  public interface FieldMessage {
    public void setMessage(byte[] m);
    public byte[] getMessage();
    public Object getParsedMessage();
  }

  public interface ITupleJSON extends ITuple{
    public void addFieldMessage (FieldMessage fm);
  }
\end{verbatim}

  E então implementar o espaço de tuplas (interfaces do LighTS estendidas) sobre a rede
P2P, conforme mostrado na Figura \ref{fig:aspectos-impl} e nos fragmentos de código a
seguir. 
  
\begin{verbatim}
  package br.usp.pcs.larc.p2pspace;
  public class MessageImpl implements FieldMessage{
  }
  
  package br.usp.pcs.larc.p2pspace;
  public class FieldImpl implements IField{
  }

  package br.usp.pcs.larc.p2pspace;
  public class TupleImpl implements ITupleJSON{
  }

  package br.usp.pcs.larc.p2pspace;
  public class P2PTupleSpace implements ITupleSpace {
  }
\end{verbatim}


  \begin{figure}[ht]
    \centering
    \includegraphics[scale=0.7]{figuras/fig-aspectos-impl.png}
    \caption{Arquitetura de Implementação}
    \label{fig:aspectos-impl}
  \end{figure}



%%----------------------------------------------------------------------------
% Modelagem Formal
%
\section{Modelagem Formal}

   Conforme já mencionado nos objetivos deste trabalho (seção \ref{sec:objetivos}), a
validação da arquitetura baseada em espaço de tuplas será feita através de modelagem
formal com redes de petri coloridas. Para auxiliar o leitor em uma melhor
compreensão dos modelos, uma introdução sobre a notação CPN e o funcionamento do
simulador foi incluída no Apêndice \ref{app:apendice-cpn}.
%
% Modelo SIPSpace
%
\subsection{Modelo CPN para o SIPSpace}
\label{subsec:CPNSipSpace}

   Para validar o SIPSpace do ponto de vista funcional, foi utilizado um modelo
CPN não-hierárquico temporizado (\textit{Non-Hierarchical Timed CPN}). Conforme
estudado em \cite{SIP-CPN_2011}, \cite{SIP-CPN_WASET}, e
\cite{SIP-TimedCPN_2011}, o modelo para análise funcional do SIPSpace
considera a transação SIP INVITE, seguindo as especificações \cite{rfc3261} e
\cite{rfc6026}. 

   A transação INVITE considera duas máquinas de estado, transação cliente (\textit{Client
Transaction}) e transação servidor (\textit{Server Transaction}):

\begin{description}

 \item[Transação Cliente: ] A transação cliente é criada pelo dispositivo
quando uma requisição INVITE é criada. Nesse momento, a transação cliente pode
alcançar cinco estados, \textit{calling}, \textit{proceeding},
\textit{accepted}, \textit{completed}, e \textit{terminated}. Adicionalmente,
quatro controladores de tempo podem ser disparados: \textit{timer A}, utilizado
para retransmissão de mensagem quando utilizado protocolo de transporte não-confiável; 
\textit{timer B}, para controlar o \textit{time-out} da transação; \textit{timer D},
responsável pelo \textit{time-out} de espera de uma resposta 3xx; e \textit{timer M},
responsável pelo \textit{time-out} de espera de uma resposta 2xx.

      Quando criada, a transação cliente assume o estado inicial
\textit{calling}; a requisição é enviada para a camada de transporte do
protocolo SIP para que seja enviada ao servidor. Nesse momento o \textit{Timer
B} é iniciado, o qual é responsável pelo controle de \textit{time-out} da
transação. O \textit{Timer A} será iniciado apenas quando utilizar um
protocolo de transporte não-confiável. Mais à frente veremos que o \textit{timer
A} é desnecessário para o SIPSpace.

      Estando no estado inicial \textit{calling}, a transação cliente pode
causar a ocorrência de alguns eventos: 
\begin{enumerate}
 \item O \textit{Timer A} pode disparar, forçando o reinício do tempo e a
retransmissão da requisição;

 \item O \textit{Timer B} pode disparar, mudando a transação para o estado
\textit{terminated}, ou seja, ocorreu um \textit{time-out};

 \item O transporte da mensagem falhar, mudando a transação para o
estado \textit{terminated}.

 \item Receber uma resposta (1xx) indicando que um recurso adicional deve
ser provisionado, mudando o estado da transação para \textit{proceeding}.

 \item Receber uma resposta (2xx) indicando que a requisição foi aceita
pelo servidor, mudando o estado da transação para \textit{accepted}.

 \item Receber uma resposta (3xx) indicando que a requisição foi recebida pelo
servidor mas não foi aceita (precisa de uma confirmação do cliente). A
transação cliente cria uma nova requisição ACK e passa para o estado
\textit{completed}.
 
\end{enumerate}

     Quando a transação cliente entra no estado \textit{accepted}, o
\textit{Timer M} deve ser iniciado. Esse \textit{timer} reflete o tempo máximo
de espera para receber uma resposta 2xx. Quando o \textit{Timer M} dispara, a
transação cliente passa para o estado \textit{Terminated}.

     Quando a transação cliente entra no estado \textit{completed}, o
\textit{Timer D} deve ser iniciado. Esse \textit{timer} reflete o tempo de
espera por uma resposta 3xx. Antes do \textit{Timer D} disparar, se uma
resposta 3xx for recebida, a transação cliente cria e envia um ACK para
o servidor, e permanece no estado \textit{completed}. Adicionalmente, caso
ocorra uma falha no envio do ACK, a transação cliente passa para o estado 
\textit{terminated}. 

     Finalmente, após entrar no estado \textit{terminated}, a transação cliente
será concluída.

     A especificação da transação cliente define os seguintes valores para os
\textit{timers}: 

      $Timer A = T1$ onde $T1 = 500ms$ 
      
      $Timer B = 64*T1$
      
      $Timer D = 0$ transporte confiável
      
      $Timer M = 0$ para transporte confiável

 %
 %
 %
 \item[Transação Servidor: ] A transação servidor é criada quando o
servidor recebe uma requisição INVITE. O servidor gera uma resposta 1xx
(\textit{trying}) e devolve para o cliente. Essa resposta provisória é
necessária para evitar que o cliente retransmita a requisição rapidamente.

     A transação servidor pode atingir cinco diferentes estados,
\textit{proceeding}, \textit{accepted}, \textit{completed}, \textit{confirmed},
e \textit{terminated}, e quatro indicadores de tempo: \textit{timer G}, utilizado em
protocolos de transportes não-confiáveis para controlar retransmissões de resposta; 
\textit{timer H}, para indicar quando a transação servidor aborta o envio de resposta;
\textit{timer I}, para indicar a finalização da transação; e \textit{timer L} utilizado
para controlar o \textit{time-out} de retransmissão de resposta r2xx.. 

     A transação servidor inicia no estado \textit{proceeding}. A partir desse
momento podem ocorrer alguns eventos:

\begin{enumerate}
 \item Disparar respostas provisórias (1xx) para os clientes,
permanecendo no estado \textit{proceeding}.

 \item A camada de transporte falhar durante o envio de uma resposta,
mantendo a transação servidor no estado \textit{proceeding}.

 \item Enviar uma resposta de sucesso (2xx), mudando o estado para
\textit{accepted}.

\item Enviar uma resposta final de insucesso (3xx), mudando e estado para 
\textit{completed}.
\end{enumerate}

      O \textit{Timer L} é iniciado quando a transação servidor entra no estado
\textit{accepted}. Esse \textit{timer} reflete o tempo que a transação servidor
espera para retransmitir uma resposta 2xx. Quando o \textit{timer L} dispara, a
transação entra no estado \textit{terminated}.

      Quando a transação entra no estado \textit{completed}, o \textit{Timer
H} é iniciado. Esse \textit{timer} determina quando o servidor abandona a
retransmissão de uma resposta. Ao disparar, a transação entra no estado 
\textit{terminated}. Se estiver utilizando um transporte não-confiável, o
\textit{Timer G} será iniciado para controlar o tempo entre cada retransmissão
da resposta 3xx. 

      Enquanto estiver no estado \textit{proceeding}, se um ACK for
recebido a transação entra no estado \textit{confirmed} e o \textit{Timer I} é
iniciado. Quando o \textit{timer I} disparar, a transação entrara no estado 
\textit{terminated} e será finalizada.

      A especificação da transação servidor define os seguintes valores para
os \textit{timers}: 

      $Timer G = T1$ onde $T1 = 500ms$
      
      $Timer H = 64*T1$
      
      $Timer I = 0$ para transporte confiável
      
      $Timer L = 64*T1$

\end{description}


   A Tabela \ref{tbl:global-declarations-nhcpn} apresenta  as declarações utilizadas no
modelo, e a Figura \ref{fig:cpnmodel} apresenta o modelo CPN para a transação INVITE no
contexto do SIPSpace, seguindo as especificações apresentadas anteriormente.

   \begin{table}[htbp]
    \centering
    \caption{Declarações para o modelo CPN da Figura \ref{fig:cpnmodel}}
    \label{tbl:global-declarations-nhcpn}
    %\vspace{0.5cm}
    %\hspace{0.5cm}  
    \begin{tabular}{|p{14.0cm}|}
        \hline \texttt{globref sendRespControl = 0;}\\
        \hline \texttt{colset CLIENT\_STATES = with calling | proceeding | completed |
accepted | terminated}; \\
        \hline \texttt{colset SERVER\_STATES = with idle | proceedingS | completedS |
acceptedS | confirmedS | terminatedS;}\\
        \hline \texttt{colset REQUEST = with INVITE | ACK | noneReq timed;}\\
        \hline \texttt{colset RESPONSE = with r1xx | r2xx | r3xx| noneResp timed;}\\
        \hline \texttt{colset TUPLE = product REQUEST * RESPONSE timed;}\\
        \hline \texttt{var ti : TIMED\_IND;}\\
        \hline \texttt{var clientState : CLIENT\_STATES;}\\
        \hline \texttt{var serverState : SERVER\_STATES;}\\
        \hline \texttt{var req : REQUEST;}\\
        \hline \texttt{var resp : RESPONSE;}\\
        \hline
    \end{tabular}
   \end{table}

  \begin{sidewaysfigure}
    \centering
    \includegraphics[scale=0.5]{figuras/fig-cpn-InviteTransaction.png}
    \caption{Modelo CPN para Transação INVITE - Validação Funcional}
    \label{fig:cpnmodel}
  \end{sidewaysfigure}  
  
  Conforme observado na Tabela \ref{tbl:global-declarations-nhcpn}, o modelo
define o seguinte conjunto de \textit{Cores}. 
  \begin{itemize}
   \item CLIENT\_STATES representa os estados da transação
cliente, \textit{calling}, \textit{proceeding}, \textit{accepted}, e
\textit{terminated}.

   \item SERVER\_STATES representa os estados da transação
servidor, \textit{proceeding}, \textit{completed}, \textit{accepted},
\textit{confirmed} and \textit{terminated}. Para evitar duplicidade com os
estados definidos na \textit{Cor} CLIENT\_STATES, foi acrescentado o sufixo 
"\textit{S}" nos estados da transação servidor.  Para propósitos de modelagem,
foi adicionado o estado inicial \textit{idle}.

   \item REQUEST representa os métodos INVITE e ACK. Adicionalmente, para
propósitos de modelagem foi definido o método \textit{noneReq} para indicar ao
modelo quando uma tupla é de requisição ou não.

   \item RESPONSE representa as classes de resposta do protocolo SIP, ou
seja, r1xx, r2xx, r3xx. Para propósitos de modelagem, foi criado uma resposta
\textit{noneResp} para indicar ao modelo quando uma tupla é de resposta ou não.

   \item TUPLE representa os dados publicados no espaço de tuplas. No modelo,
uma tupla recebe valores dos tipos REQUEST e RESPONSE. Quando o primeiro valor
é um \textit{noneReq}, significa que é uma tupla de resposta. Quando o segundo
valor é \textit{noneResp}, significa que é uma tupla de requisição.

  \end{itemize}

   Para adicionar expressividade ao modelo visando alcançar a correta transição
de estado conforme especificação da transação SIP INVITE, foram definidas algumas funções
CPN-ML. Os códigos CPN-ML a seguir ilustram o funcionamento de cada uma das funções.

\begin{description}
 \item[Delay(): ] A função \texttt{Delay} é utilizada para simular o tempo
gasto para transmitir mensagens pela rede. Para efeitos de modelo, utilizamos
uma distribuição exponencial para gerar intervalos de tempo de 5ms.
\begin{verbatim}
 1. fun Delay() = 
 2.   exponential(0.2);
\end{verbatim}

  \item[OT(): ] A função \texttt{OT} (i.e. \textit{O}ver \textit{T}ime) é utilizada para
verificar a ocorrência de time out na execução da transação INVITE. A função recebe um
parâmetro \textit{timeout} e um parâmetro \textit{timecall} que representa o tempo atual
da simulação, chamado pelo simulador CPN de \textit{Model Time}, no momento em que a
tupla é publicada no espaço (\textit{Lugar} \textit{Tuple Space}).
\begin{verbatim}
 1. fun OT(timeout:INT,timecall:INT) =
 2.  let
 3.    val timepass = intTime() - timecall
 4.  in
 5.    if (timepass > timeout) then 
 6.      true
 7.    else 
 8.      false
 9.  end;
\end{verbatim}

  \item[chooseResp(): ] A função \texttt{chooseResp} é utilizada para gerar as
respostas SIP de acordo com o contexto da simulação. A função tem uma
\textit{flag} para controlar a primeira execução. Na primeira execução, a função
utiliza uma distribuição discreta de probabilidade para selecionar a resposta
entre r2xx e r3xx. Na próxima execução, a escolha será oposta à primeira, ou
seja, se a primeira execução retornou r2xx, a segunda execução irá retornar
r3xx.
\begin{verbatim}
 1. fun chooseResp(ss:SERVER_STATES,lastResp:RESPONSE) = 
 2.  let
 3.    val i = discrete(0,2)
 4.    fun increment() = (inc sendRespControl)
 5.  in
 6.    increment();
 7.    if !sendRespControl = 1 then
 8.       if i=0 then 1`r3xx
 9.       else 1`r2xx
10.    else
11.       if lastResp = r2xx then empty
12.       else 1`r2xx
13.  end;
\end{verbatim}

  \item[changeClientState: ] A função \texttt{changeClientState} é responsável
por implementar as regras de transição de estado do lado do cliente.
\begin{verbatim}
 1. fun changeClientState(resp:RESPONSE,cs:CLIENT_STATES) =
 2.   if resp=r1xx andalso cs=calling then
 3.     proceeding
 4.   else
 5.     if resp=r3xx andalso cs<>accepted then 
 6.       completed
 7.     else
 8.       if resp=r2xx then 
 9.         accepted
 9.       else 
10.         cs;
\end{verbatim}

\end{description}


   No modelo CPN para o SIPSpace, Figura \ref{fig:cpnmodel}, pode-se observar a
transação cliente do lado esquerdo e a transação servidor do lado direito.

   A transação cliente é modelada com dois lugares, \texttt{ClientTransaction} e
\texttt{SendRequest}, e duas transições, \texttt{WriteTupleC}, a qual representa a
operação \texttt{out} e \texttt{ReadTupleC}, a qual representa a operação \texttt{in},
ambas do paradigma de programação com espaço de tuplas. A transição \texttt{ClientErr}
representa a ocorrência de erros de transmissão e \textit{timeout} (\textit{timers} B, D,
e M).

   Assim como na transação cliente, a transação servidor é modelada com dois
lugares, \texttt{ServerTransaction} e \texttt{SendResponse}, e duas
transições, \texttt{WriteTupleS}, a qual representa a operação \texttt{out} e
\texttt{ReadTupleS}, a qual representa a operação \texttt{in}. A transição
\texttt{ServerErr} representa a ocorrência de erros de transmissão e \textit{timeout}
(\textit{timers} H, I, e L).

   O lugar \texttt{Tuple Space} é uma abstração do espaço de tuplas que recebe as
marcações representando as tuplas, ou seja, as mensagens de requisição e resposta.

   O modelo CPN para o SIPSpace desconsidera os \textit{timers} A e G. Ambos são
utilizados quando a camada de transporte é implementada sob canais não-confiáveis, porém,
no contexto do SIPSpace assumiu-se que a implementação de espaço de tuplas sempre
irá utilizar canais confiáveis para transporte de mensagens.

   A simulação inicia com a marcação \texttt{1`calling} no lugar
\texttt{ClientTransaction}, a marcação \texttt{1`INVITE@0} no lugar \texttt{SendRequest}
e a marcação \texttt{1`idle} no lugar \texttt{ServerTransaction}. A simulação considera
o fluxo completo de uma requisição entre um dispositivo cliente e o servidor SIP. 

   Conforme a especificação SIP INVITE, ao final da simulação os lugares \texttt{Client
Transaction} e \texttt{Server Transaction} devem estar no estado \textit{terminated} e 
\textit{terminatedS} respectivamente.

   Estando o lugar \texttt{ClientTransaction} com a marcação \texttt{1`calling}, e o
lugar \texttt{SendRequest} com a marcação \texttt{1`INVITE}, a transição
\texttt{WriteTupleC} é habilitada para início da simulação. A partir desse momento, a
simulação segue a especificação definida para o cliente e o servidor.


%% ==========================================================================

%
% Modelo SIPSpace
%
\subsection{Modelo CPN para a Rede IMS Baseada em Espaço de Tuplas}\label{cpn-redesims}

   A ferramenta CPN Tool permite desenvolver redes de petri coloridas de forma
hierárquica, ou seja, é possível criar um modelo alto nível composto por módulos
representando componentes do sistema. No contexto da arquitetura baseada em espaço de
tuplas, foi criado um modelo alto nível representando a topologia da rede com os
Domínios A e B, sendo que o Domínio A representa a rede P2P com 4 Servidores IMS
conectados. As Figuras \ref{fig-cpn-p2p}, \ref{fig-cpn-node}, \ref{fig-cpn-arrival},
\ref{fig-cpn-device}, \ref{fig-cpn-lts}, \ref{fig-cpn-server} ilustram os detalhes do
modelo. 

   A Tabela \ref{tbl:color-sets} apresenta a declaração do conjunto de "cores" definidos
para o modelo CPN da arquitetura baseada em espaço de tuplas utilizado na análise de
desempenho.

  \begin{table}[htbp]
    \centering
    \caption{Conjunto de cores para os modelos CPN da arquitetura baseada em espaço de
tuplas}
    \label{tbl:color-sets}
    \begin{tabular}{ |p{14.0cm}| }
        \hline \texttt{colset P2PNODE = with node1 | node2 | node3 | node4 | domainB;}\\
        \hline \texttt{colset REQUEST = with REGISTER | INVITE | PRACK | ACK | noReq;}\\
        \hline \texttt{colset RESPONSE = with r200 | r401 | r183 | noResp;}\\
        \hline \texttt{colset NO = INT timed;}\\
        \hline \texttt{colset TOA = INT;}\\
        \hline \texttt{colset SOP = INT;}\\
        \hline \texttt{colset AUTH = BOOL;}\\
        \hline \texttt{colset FINISH = BOOL;}\\
        \hline \texttt{colset TUPLE = product NO * REQUEST * RESPONSE * TOA * SOP *
P2PNODE * AUTH * FINISH timed;}\\
      \hline
    \end{tabular}
  \end{table}

\begin{itemize}
   \item P2PNODE representa os Servidores IMS que fazem parte da rede P2P. No modelo
utilizado para simulação foram considerados quatro Servidores IMS.

   \item REQUEST representa os métodos utilizados na requisição com base na
especificação SIP, e.g, REGISTER, INVITE, PRACK e ACK. Adicionalmente, para
propósitos de modelagem foi definido o método \textit{noReq} para indicar ao
modelo quando uma tupla é de requisição ou não.

   \item RESPONSE representa os códigos de resposta utilizados durante a
simulação, e.g, r200 para resposta de sucesso, r401 para usuário não autenticado
e r183 para sessão em progresso. Para propósitos de modelagem, foi criado uma
resposta \textit{noResp} para indicar ao modelo quando uma tupla é de resposta
ou não.

   \item NO representa números inteiros com marcação de tempo
    
   \item TOA representa a marcação de tempo na chegada de uma requisição
   
   \item SOP representa a marcação de tempo em um \textit{Lugar} específico
   
   \item AUTH booleano que indica se o usuário foi autenticado ou não.
   
   \item FINISH boolean que indica que o processamento no CSCF foi finalizado.

   \item TUPLE representa os dados publicados no espaço de tuplas. No modelo,
uma tupla é o produto das Cores NO, REQUEST, RESPONSE, TOA, SOP, P2PNODE, AUTH e
FINISH.

\end{itemize}

   A Tabela \ref{tbl:variables} apresenta as variáveis utilizadas no modelo.
Variáveis CPN-ML tem a mesma característica de variáveis em qualquer
linguagem de programação, porém os "tipos de dados" são as "cores".

  \begin{table}[ht]
    \centering
    \caption{Declarações de variáveis para os modelos CPN da arquitetura baseada em espaço
de tuplas}
    \label{tbl:variables}
    %\vspace{0.5cm}
    %\hspace{0.5cm}  
    \begin{tabular}{|p{14.0cm}|}
        \hline \texttt{var n: NO;}\\
        \hline \texttt{var node: P2PNODE;}\\
        \hline \texttt{var toa: TOA;}\\
        \hline \texttt{var sop: SOP;}\\
        \hline \texttt{var req: REQUEST;}\\
        \hline \texttt{var resp: RESPONSE;}\\
        \hline \texttt{var auth: AUTH;}\\
        \hline \texttt{var finish: FINISH;}\\
        \hline \texttt{var i: INT;}\\
        \hline
    \end{tabular}
  \end{table}


   A Tabelas \ref{tbl:global-declarations} apresenta as declarações globais do modelo.
Essas declarações são utilizadas para simplificar a configuração do modelo, pois, uma vez
alteradas, mudam o resultado das simulações. 

  \begin{table}[ht]
    \centering
    \caption{Declarações globais para os modelos CPN da arquitetura baseada em espaço de
tuplas}
    \label{tbl:global-declarations}
    \begin{tabular}{|p{5.0cm}|p{9.0cm}|}
        \hline \texttt{globref txRegister=0.6;}        & Indica a taxa de requisições
REGISTER utilizada na simulação. O valor 0.6 indica que 60\% das requisições são do tipo
REGISTER e o restante do tipo INVITE. Esse valor foi definido de acordo com estudo
apresentado em \cite{SIPTraffic}.\\
        \hline \texttt{globref txInviteLocal=0.5;}     & Indica o percentual de
requisições do tipo INVITE que são feitas entre domínios ou no mesmo domínio. O valor
50\% foi adotado por não ter um estudo a respeito que defina esse comportamento.\\
        \hline \texttt{globref txHSSQueryLocal=0.5;}   & Indica o percentual de
consultas ao HSS que serão realizadas localmente ou através da rede. Como na arquitetura
padrão não existe essa característica, ou seja, todo acesso ao HSS é feito através da
rede, foi utilizado o valor de 50\%. \\
        \hline \texttt{globref leaseTime=1000;}        & Indica o time-out da tupla
publicada no espaço, representando o conceito de Lease do espaço de tuplas.\\
        \hline \texttt{globref iatNode1=0;}            & Indica o intervalo de tempo
entre disparos de requisição, utilizado pela função \texttt{NextArrival()}. Esse valor é
alterado a cada execução da simulação.\\
        \hline \texttt{globref loadNode1=0;}           & Indica o número de
requisições que serão disparadas; equivale a dizer o número de dispositivos conectados
em um Servidor IMS.Valor também alterado durante as simulações.\\
        \hline \texttt{globref node1Enabled=true;}     & Indica se o Servidor IMS
estará habilitado durante a simulação. \\
        \hline \texttt{globref threadsAvailable1=70;}  & Indica o número de
requisições simultâneas que o componente CSCF consegue processar. Para efeitos de
simulação, foi adotado como sendo um servidor com capacidade de 100 requisições, 30 para
o \textit{Events Processor} e 70 para o CSCF.\\
        \hline
    \end{tabular}
  \end{table}
  
  Importante destacar que as declarações globais apresentadas foram utilizadas tanto nas
simulações do modelo CPN para a arquitetura baseada em espaço de tuplas quanto para o
modelo CPN da arquitetura padrão, mantendo assim o mesmo cenário para realizar
as comparações.


   Para adicionar expressividade ao modelo visando alcançar a correta simulação
da arquitetura proposta, foram definidas algumas funções CPN ML.

\begin{description}
 \item[RANDelay: ] A função \texttt{RANDelay()} é utilizada para representar o atraso na
comunicação entre o dispositivo móvel e a rede IMS. O tempo considerado é de 100ms,
obedecendo a uma distribuição exponencial, conforme código CPN-ML apresentado a seguir.
\begin{verbatim}
    1. fun RANDelay () = 
    2.    exponential(0.01);
\end{verbatim}
 

  \item[LTSAccessDelay: ] A função \texttt{LTSAccessDelay()} define o atraso
durante o acesso ao LTS. A função utiliza uma distribuição exponencial de 10ms.
\begin{verbatim}
      1. fun LTSAccesDelay() = 
      2.    exponential(0.1);
\end{verbatim}


 \item[DTSAccessDelay: ] A função \texttt{DTSAccessDelay()} define o atraso no acesso ao
DTS. A função gera números obedecendo uma distribuição exponencial. Para o modelo, estamos
considerando uma intensidade de $0.07$ para a função, o qual representa uma distribuição
exponencial de intervalo de tempo de 15ms.
\begin{verbatim}
    1. fun DTSAccessDelay() = 
    2.    exponential(0.07);
\end{verbatim}


  \item[DomainBDelay: ]A função \texttt{DomainBDelay()} representa o tempo de
processamento no domínio B, gerando intervalos de tempo de 160ms, através de distribuição
exponencial.
\begin{verbatim}
  1. fun DomainBDelay() = 
  2.  exponential(0.006);
\end{verbatim}

  \item[InterDomainDelay: ] A função \texttt{InterDomainDelay()} é utilizada para
representar o atraso na comunicação entre o Domínio A e o Domínio B. A função gera
intervalos de tempo de 25ms obedecendo a uma distribuição exponencial conforme mostra o
código CPN-ML apresentado a seguir.
\begin{verbatim}
    1. fun InterDomainDelay()= 
    2.    exponential(0.04);
\end{verbatim}

  \item[HSSQueryTime: ] A função \texttt{HSSQueryTime()} representa o tempo
gasto para realização de consultas no HSS. Pela arquitetura baseada em espaço
de tuplas, uma consulta ao HSS pode ser feita localmente ou em qualquer Servidor IMS da
rede. A função utiliza uma distribuição uniforme de probabilidade para decidir
se a consulta será feita local ou na rede. Para efeitos de simulação,
consideramos uma taxa de 50\% de consultas local e 50\% de consultas remota,
valor este definido pela variável global \texttt{txHSSQueryLocal}. No caso, foram
adotados 2s para acesso local e 15s para acesso remoto, conforme utilizado por
\cite{QPN-IMS}
\begin{verbatim}
  1. fun HSSQueryTime() = 
  2. let
  3.   val hd = !txHSSQueryLocal;
  4. in
  5.   if (uniform(0.0,1.0) <= hd) then  
  6.    2
  7.   else  
  8.    15
  9. end;
\end{verbatim}

  \item[CSCFProcessingTime: ] A função \texttt{CSCFProcessingTime()} representa
o tempo de processamento no CSCF. A função gera intervalos de tempo de 3ms utilizando
distribuição exponencial.
\begin{verbatim}
  1. fun CSCFProcessingTime() = 
  2.  exponential(0.3);
\end{verbatim}

  \item[InviteTargetUEdelay: ] A função \texttt{InviteTargetUEdelay} representa
o atraso durante o envio de requisição INVITE para o UE destino. UEs destino
podem estar na mesma rede ou em domínios diferentes. A variável global
\texttt{txInviteLocal} simula o percentual de requisições locais e remotas.
Para efeito de simulação, estamos considerando 50\% de requisições locais e
50\% de requisições remotas. Para requisições na rede local o atraso é de 50ms e para
requisições remotas o atraso é de 160ms, ambos com distribuição exponencial.
   \begin{verbatim}
      fun InviteTargetUEdelay() =
      let
         val invite = uniform(0.0,1.0)
      in
         if (invite <= (!txInviteLocal)) then
           exponential(0.02)
         else
           exponential(0.006)
      end;
\end{verbatim}


  \item[initSim1: ] A função \texttt{initSim1()} é utilizada para inicializar a
variável global \texttt{threadsAvailable1}, ou seja, garantir que ao iniciar a
simulação o número de \textit{threads} disponíveis para processamento de tuplas
do Servidor IMS representado por \textit{node1} é igual ao máximo definido. O mesmo vale
para cada um dos Servidores IMS da rede, e.g \texttt{initSim2}, \texttt{initSim3}, etc.
\begin{verbatim}
   1. fun initSim1() =
   2.  let
   3.    fun initThreadsAvailable () = threadsAvailable1:=70;
   4.  in
   5.    initThreadsAvailable();
   6.    1`1
   7.  end;
\end{verbatim}

  \item[NextArrival: ] A função \texttt{NextArrival()} utiliza a função de
distribuição de Poisson para gerar intervalos de tempo com base no parâmetro
\texttt{iat} (\textit{inter-arrival time}). Essa função é utilizada para determinar a
carga de requisições para a simulação. Como exemplo, ao passar o parâmetro \texttt{iat
= 15}, estamos considerando para efeito de simulação um intervalo de de 15ms
entre cada requisição, o equivalente a 240000 requisições p/hora obedecendo a
uma distribuição de Poisson.
\begin{verbatim}  
   1. fun NextArrival iat = 
   2.     poisson(iat);
\end{verbatim}

  \item[CreateTuple: ] A função \texttt{CreateTuple()} é responsável por gerar
requisições utilizando a cor \texttt{TUPLE}. Como o modelo considera
requisições de registro e de estabelecimento de sessão, essa função é
responsável por gerar os dois tipos de maneira uniforme. Para isso, utilizamos
a variável global \texttt{txRegister} que é definida inicialmente com valor
0.6, conforme mostra a Tabela \ref{tbl:global-declarations}, indicando que 60\%
das tuplas geradas são requisições do tipo REGISTER. 
\begin{verbatim}    
 1. fun CreateTuple(n:NO, node:P2PNODE) =
 2.  let
 3.    val t = time()
 4.    val at = IntInf.toInt (RealToIntInf 0 t)
 5.    val reqType = uniform(0.0,1.0)
 6.  in
 7.    if (reqType <= !txRegister) then
 8.      1`(n,REGISTER,noResp,IntTime(),0,node,false,false)
 9.    else
10.      1`(n,INVITE,noResp,IntTime(),0,node,false,false)
11.  end;
\end{verbatim} 

  \item[LeaseTimeout: ] A função \texttt{LeaseTimeout()} é responsável por
habilitar a transição \texttt{Lease} do modelo apresentado na Figura
\ref{fig-cpn-lts}. O parâmetro \texttt{sop} recebido, representa o tempo no
momento em que a tupla foi publicada no LTS. A função verifica se a tupla está
em espera para processamento um tempo maior do que o definido pela variável
global \texttt{leaseTime}. 
\begin{verbatim}
 1. fun LeaseTimeout sop =
 2.  let
 3.    val timeSpent = (IntTime()-sop)
 4.  in
 5.    if(timeSpent > (!leaseTime)) then  
 6.     true
 7.    else  
 8.     false
 9.  end;
\end{verbatim}

  \item[HoldThread1: ] A função \texttt{HoldThread1()} é utilizada para
decrementar o número de \textit{threads} disponíveis no CSCF para processamento de
requisições. 
\begin{verbatim}
  1. fun HoldThread1() = 
  2. let
  3.   val ta = (!threadsAvailable1) - 1
  4.   fun decThreadsAvailable ta = (threadsAvailable1:=ta)
  5. in
  6.   decThreadsAvailable(ta);
  7.   if (!threadsAvailable1 = 0) then 
  8.     1`1
  9.   else 
 10.     empty
  end;
\end{verbatim}

  \item[ReleaseThread1: ] A função \texttt{ReleaseThread1()} é utilizada para
incrementar o número de \textit{threads} disponíveis no CSCF para processamento de
requisições. Em conjunto com a função \texttt{HoldThread1()}, faz o controle da
capacidade de processamento paralelo do CSCF durante a simulação.
\begin{verbatim}
  1. fun ReleaseThread() = 
  2. let
  3.   val ta = (!threadsAvailable1) + 1
  4.   fun incThreadsAvailable ta = (threadsAvailable1:=ta)
  5. in
  6.   incThreadsAvailable (ta);
  7.   1
  8. end;
\end{verbatim}

\end{description}

   A Figura \ref{fig-cpn-p2p} apresenta o modelo CPN hierárquico representando a
topologia da rede. Como é possível observar, o \textsc{Domínio A} consiste de um espaço de
tuplas distribuído, representado pelo lugar \texttt{DTS}, e quatro Servidores
IMS  conectados ao DTS, representados pelos módulos \texttt{Node1}, \texttt{Node2},
\texttt{Node3} e \texttt{Node4}. 

  \begin{sidewaysfigure}
    \centering
    \includegraphics[scale=0.6]{figuras/fig-cpn-p2p.png}
    \caption{Modelo CPN Hierárquico representando a rede IMS baseada em espaço de tuplas}
    \label{fig-cpn-p2p}
  \end{sidewaysfigure}

   Em cada um dos Servidores IMS existe uma transição representando a operação
\texttt{out()} e outra transição representando a operação \texttt{in()} do paradigma de
programação baseado em espaço de tuplas. Cada uma dessas transições possui a função
\texttt{DTSAccessDelay()} associada para representar o atraso no acesso ao DTS.

   A estratégia de modelagem adotada considerou que cada Servidor IMS da rede,
representados pelos módulos \texttt{Node1}, \texttt{Node2}, \texttt{Node3} e
\texttt{Node4} no modelo da Figura \ref{fig-cpn-p2p}, também serão representados através
de um modelo CPN hierárquico, conforme mostra a Figura \ref{fig-cpn-node}. 

   \begin{figure}[h!]
     \centering
     \includegraphics[scale=0.5]{figuras/fig-cpn-node.png}
     \caption{Modelo CPN Hierárquico representando um Servidor IMS da rede}
     \label{fig-cpn-node}
   \end{figure} 

   O modelo consiste dos seguintes módulos:

   \begin{itemize}
      \item \texttt{Arrival Node1}, responsável pela modelagem da chegada de requisições
na rede através de um servidor IMS específico.

      \item \texttt{Devices Node1}, um modelo CPN representando um dispositivo enviando
e recebendo mensagens.

      \item \texttt{LTS Node1}, que modela o espaço de tuplas local.
      
      \item \texttt{Server Node1} que modela o funcionamento do Servidor IMS em relação
aos componentes \textit{Events Processor}, CSCF e HSS.

   \end{itemize}


   
   A Figura \ref{fig-cpn-arrival} apresenta o modelo CPN para o módulo \texttt{Arrival
Node1}. 

   \begin{figure}[h!]
     \centering
     \includegraphics[scale=0.5]{figuras/fig-cpn-arrival.png}
     \caption{Modelo CPN representando a chegada de requisições (\textit{Arrival Node})}
     \label{fig-cpn-arrival}
   \end{figure}    
   
   O módulo \texttt{Arrival Node1} representa a chegada de requisições na rede através de
um Servidor IMS específico. O lugar \texttt{Start} inicia com uma marcação que habilita
a transição \texttt{starting}. Após o disparo da transição, a função \texttt{initSim1()}
é executada para iniciar as variáveis globais do modelo.

   O lugar \texttt{Next Arrival} e a transição \texttt{Arrival Node1} representam a
chegada de requisições propriamente ditas. A cada disparo da transição \texttt{Arrival
Node1} a função \texttt{NextArrival(!iatNode1)} é executada para incrementar o tempo do
modelo, fazendo com que uma nova requisição seja gerada após um intervalo de tempo. 

   Conforme discutido em \cite{QPN-IMS}, a chegada de requisições em uma rede
IMS obedece à distribuição de Poisson. A função CPN-ML \texttt{NextArrival(!iatNode1)} irá
utilizar como intensidade da função de Poisson o parâmetro \texttt{iat}, o qual irá
determinar o número de requisições por segundo disparadas durante a simulação.

   É importante observar que a transição \texttt{Arrival Node1} possui a
guarda \texttt{[(!node1Enabled)=true andalso n<=(!loadNode1)]}. Isso garante que
a transição só será disparada quando o Servidor IMS estiver habilitado e enquanto o
número de requisições for menor que o total de requisições configurado, representado pela
variável \texttt{loadNode1}. Nesse caso, a a variável \texttt{loadNode1} representa o
número de dispositivos conectados em um Servidor IMS.


   A Figura \ref{fig-cpn-device} apresenta o modelo CPN para o módulo
\texttt{Device Node1}. Esse modelo representa o fluxo de mensagens de
requisição e resposta dos dispositivos conectados à rede. 

   \begin{figure}[h!]
     \centering
     \includegraphics[scale=0.5]{figuras/fig-cpn-devices.png}
     \caption{Modelo CPN representando os dispositivos conectados à rede
(\textit{Devices})}
     \label{fig-cpn-device}
   \end{figure}   
   
   O lugar \texttt{N1A} representa a conexão do módulo \texttt{Arrival Node1} com o
módulo \texttt{Device Node1}, ou seja, representa a ação do usuário ligando um dispositivo
para se registrar na rede ou iniciando uma sessão. 

   O disparo da transição \texttt{Create Request} causa a execução da função CPN-ML
\texttt{CreateTuple(n,node1)}, responsável pela geração de uma marcação com a cor
\texttt{TUPLE} no lugar \texttt{Client Transaction}.

   O disparo da transição \texttt{Send Request} representa a publicação de uma tupla no
LTS. A cada disparo, o tempo do modelo é incrementado pela função \texttt{RANDelay()},
representando o atraso na comunicação do UE com a rede. Conforme explicado em
\cite{QPN-IMS}, o atraso considerado na simulação é de 100ms.

   A transição \texttt{Receive Response} representa o recebimento de uma mensagem pelo
dispositivo (e.g., a leitura de uma tupla no LTS). O disparo desta transição causa a
execução do código CPN-ML apresentado a seguir, que gera uma marcação no lugar
\texttt{Client Transaction} de acordo com o tipo de resposta recebida. 

        \noindent\textit{\textbf{Código CPN-ML} - Define o comportamento do
dispositivo em função da resposta\footnote{Detalhes da notação utilizada no código podem
ser lidos no Apêndice \ref{app:apendice-cpn}}}
        \begin{algorithm}
          \begin{algorithmic}[1]
            \STATE if(resp=r401) then
               \STATE\hspace{\algorithmicindent}
1`(n,req,noResp,toa,sop,node,true,false)
            \STATE else if(resp=r183) then
               \STATE\hspace{\algorithmicindent}
1`(n,PRACK,noResp,toa,sop,node,auth,finish)            
            \STATE else if(resp=r200 andalso req=PRACK) then
               \STATE\hspace{\algorithmicindent}
1`(n,ACK,noResp,toa,sop,node,auth,finish)            
            \STATE else
               \STATE\hspace{\algorithmicindent}
1`(n,req,resp,toa,sop,node,auth,finish)           
          \end{algorithmic}
        \end{algorithm}


      A Figura \ref{fig-cpn-lts}  apresenta o modelo CPN para o módulo \texttt{LTS
Node1}. O lugar \texttt{LTS Node1} representa o espaço de tuplas. As transições
\texttt{outC} e \texttt{inC} representam as operações de leitura e escrita no LTS
realizadas por um dispositivo. As transições \texttt{outS} e \texttt{inS} representam
as operações de leitura e escrita no LTS realizadas pelo Servidor IMS (componentes
\textit{Events Processor} e CSCF).

   \begin{figure}[h!]
     \centering
     \includegraphics[scale=0.5]{figuras/fig-cpn-lts.png}
     \caption{Modelo CPN para o espaço de tuplas local (LTS)}
     \label{fig-cpn-lts}
   \end{figure}  

   As transições de leitura e escrita possuem a função CPN-ML \texttt{LTSAccessDelay}
associada, representando o tempo gasto em cada operação.

   Adicionalmente, o modelo também representa o conceito de \textit{Lease} implementado
pelo espaço de tupla. \textit{Lease} é uma marcação que determina o tempo de vida de
uma tupla após ser inserida no espaço. No modelo CPN isto é representado pela
transição \texttt{Lease} que está associada à função CPN-ML
\texttt{LeaseTimeout()}. Quando a função retornar \texttt{true}, a transição
será habilitada fazendo com que a tupla seja publicada no LTS novamente
(\textit{lease renew}).


    A Figura \ref{fig-cpn-server} apresenta o modelo CPN para o módulo
\texttt{Server Node1}. Esse modelo representa o funcionamento do Servidor IMS em relação
ao gerenciamento de sessão e o comportamento do componente \textit{Event Processor},
responsável pela iteração com o espaço de tuplas.

   \begin{sidewaysfigure}
    \centering
    \includegraphics[scale=0.6]{figuras/fig-cpn-server.png}
    \caption{Modelo CPN para o CSCF e o Event Processor}
    \label{fig-cpn-server}
   \end{sidewaysfigure}    


    O \textit{Event Processor} é representado no modelo pelos lugares
\texttt{Event Processor Idle} e \texttt{Event Processor Working}, e pelas
transições \texttt{in LTS} e \texttt{in DTS}. A marcação no lugar \texttt{Event Processor
Idle} representa o número de \textit{threads} disponíveis para realizar leitura de
tuplas. Para o contexto desse trabalho, considerou-se uma capacidade de realizar a
leitura de 30 tuplas simultaneamente.

    Ao ler uma tupla do LTS, a transição \texttt{Process Tuple}
poderá ser habilitada, determinando o início do processamento da requisição
pelo CSCF, representado no modelo pelo lugar \texttt{CSCF}. A capacidade do servidor em
processar tuplas simultaneamente é representada pelo lugar \texttt{CSCF Idle}, tendo como
início a marcação \texttt{70`1}, ou seja, consegue processar 70 requisições
simultaneamente. 

    O balanceamento de carga realizado pelo \textit{Events Processor} é representado no
modelo pelos lugares \texttt{CSCF Idle} e \texttt{DTS enabled}. Quando a
marcação do lugar \texttt{CSCF Idle} chega a um valor zero, ou seja, CSCF totalmente
ocupado, o lugar \texttt{DTS enable} recebe a marcação \texttt{1'1}, indicando que as
tuplas lidas do LTS deverão ser publicadas no DTS para que sejam processadas por qualquer
outro Servidor IMS da rede com menor carga. Para propósitos de modelagem, esse controle é
feito através das funções CPN-ML \texttt{HoldThread1()} e \texttt{ReleaseThread1()}. 


    É importante observar que na arquitetura IMS padrão, o CSCF é subdivido em três
elementos, P-CSCF, S-CSCF e I-CSCF. Na arquitetura baseada em espaço de tuplas 
foi definida a existência de um único elemento CSCF que contempla todas as
funcionalidades, conforme apresentado no capítulo \ref{cap:arquitetura}.

    Ao receber uma tupla, o CSCF poderá realizar o registro do dispositivo na
rede, caso seja uma requisição do tipo REGISTER ou estabelecer uma sessão com
outro dispositivo, caso seja uma requisição do tipo INVITE. Para efeitos de
modelagem, cada um dos dois tipos de requisição foi modelado com seus
respectivos lugares e transições. 

   A operação de registro é representada pelo lugar \texttt{REG} e pelas
transições \texttt{Process Registration}, \texttt{Query HSSreg} e \texttt{Return
Registration}. A transição \texttt{Query HSSreg} está associada à função CPN-ML
\texttt{HSSQueryTime()} representando o tempo gasto para realizar uma consulta no HSS.  
Após a consulta ao HSS, será gerada uma resposta indicando usuário
autenticado (r200) ou falha de autenticação (r401). Adicionalmente, a transição
\texttt{Return Registration} está associada à função CPN-ML
\texttt{CSCFProcessingTime()}, a qual representa o tempo de processamento do CSCF.

    A operação de estabelecimento de sessão é representada pelo lugar \texttt{INV}, e
pelas transições \texttt{Process SessionSetup}, \texttt{Return Invite}, \texttt{Query
HSSInv} e \texttt{inv-target}. A transição \texttt{Query HSSInv} está associada
à função CPN-ML \texttt{HSSQueryTime()}, representando o tempo gasto para realizar uma
consulta no HSS. O mesmo ocorre com a operação de registro. A transição
\texttt{inv-target} representa a comunicação com o dispositivo alvo ao qual se deseja
estabelecer uma sessão. Esta transição está associada à função CPN-ML
\texttt{InviteTargetUEdelay()}, que representa o tempo de comunicação do Servidor IMS com
o dispositivo alvo. Adicionalmente, a transição \texttt{Return Invite} está associada
à função CPN-ML \texttt{CSCFProcessingTime()}, a qual representa o tempo de processamento
do CSCF.


%      Por fim, a Figura \ref{fig-cpn-domainB-p2p} representa um domínio de rede
% externo (Visited Network). Para simplificar o modelo, o Domínio B possui apenas
% lugares e transições representando a chegada de requisições e os dispositivos,
% e a comunicação com o Domínio A (Home Network). 
% 
%    \begin{figure}[ht]
%      \centering
%      \includegraphics[scale=0.55]{figuras/fig-cpn-domainB.png}
%      \caption{Modelo CPN simplificado para o Domínio B}
%      \label{fig-cpn-domainB-p2p}
%    \end{figure} 
%    
%      A \textit{Transição} \textit{"Send IMSNet DomainB"} representa a
% comunicação do Domínio B com o Domínio A. Esta transição está associada à função
% CPN-ML \texttt{DomainBDelay()}, representando o tempo de processamento de
% mensagens dentro da própria rede. 


    O modelo CPN da arquitetura baseada em espaço de tuplas apresentado
anteriormente possibilita a simulação com diferentes cenários e parâmetros.

\begin{itemize}
 \item permite habilitar/desabilitar Servidores IMS.

 \item permite alterar a taxa de chegada de requisições no sistema através dos parâmetros
de intervalo entre requisições.
 
 \item possibilita a simulação do comportamento considerando diferentes tempos
de atraso nos diversos elementos da rede.

 \item possibilita a simulação do comportamento do sistema alterando parâmetros
de capacidade de processamento simultâneo dos componentes CSCF e \textit{Event
Processor}.

\end{itemize}

